其他
全面解读数据中台、数据仓库和数据湖
点击上方 "云祁QI"关注, 星标或置顶一起成长
如今，随着诸如互联网以及物联网等技术的不断发展，越来越多的数据被生产出来。据统计，每天大约有超过2.5亿亿字节的各种各样数据产生。这些数据需要被存储起来并且能够被方便的分析和利用。
1.1 数据库
关系数据库本质上是一个二元关系，说的简单一些，就是一个二维表格，对普通人来说，最简单的理解就是一个Excel表格。这种数据库类型，具有结构化程度高，独立性强，冗余度低等等优点，一下子就促进了计算机的发展。1.2 操作型数据库和分析型数据库
随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：操作型数据库
主要用于业务支撑。一个公司往往会使用并维护若干个操作型数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等；分析型数据库
主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；那么为什么要'分家'？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？答案是NO。一个显然的原因是它们会'打架'…如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已'貌合神离'。接下来看看它们到底有哪些不同吧。1.3 操作型数据库 VS 分析型数据库
因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。这就好像同样是人，但一个和尚和一个穆斯林肯定有很多行为/观念上的不同。接下来本文将详细分析两类数据库的不同点：
数据组成差别 - 数据时间范围差别
一般来讲，操作型数据库只会存放90天以内的数据，而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。数据组成差别 - 数据细节层次差别
操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。操作型数据库中自然也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。而对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。数据组成差别 - 数据时间表示差别
操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时刻的快照，分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。技术差别 - 查询数据总量和查询频度差别
操作型查询的数据量少而频率多，分析型查询则反过来，数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔的原因之一。技术差别 - 数据更新差别
操作型数据库允许用户进行增，删，改，查；分析型数据库用户则只能进行查询。技术差别 - 数据冗余差别
数据的意义是什么？就是减少数据冗余，避免更新异常。而如5所述，分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。现在回到开篇是提到的第二个问题'某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？'，答曰是正常的。因为Hive是一种数据仓库，而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口，不提供更新接口，这就使得消除冗余的诸多措施不需要被特别严格地执行了。功能差别 - 数据读者差别
操作型数据库的使用者是业务环境内的各个角色，如用户，商家，进货商等；分析型数据库则只被少量用户用来做综合性决策。功能差别 - 数据定位差别
这里说的定位，主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的，因此也被称为'面向应用型数据库'；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为'面向主题型数据库'。2.1 概述
数据仓库就是为了解决数据库不能解决的问题而提出的。那么数据库无法解决什么样的问题呢？这个我们得先说说什么是OLAP和OLTP。2.2 OLTP和OLAP
2.2.1 OLTP
OLTP（OnLine Transaction Processing 联机事务处理） 。简单一些，就是数据库的增删查改。举个例子，你到银行，去取一笔钱出来，或者转账，或者只是想查一下你还有多少存款，这些都是面向“事务”类型的操作。这样的操作有几个显著的特点:首先要求速度很快， 基本上都是高可靠的在线操作（比如银行）， 还有这些操作涉及的数据内容不会特别大（否则速度也就相应的降低）， 最后，“事务”型的操作往往都要求是精准操作，比如你去银行取款，必须要求一个具体的数字，你是不可能对着柜台员工说我大概想取400到500快之间吧，那样人家会一脸懵逼。2.2.2 OLAP
这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂，但这里我举一个简单的例子，大家就很容易理解了。比如说，沃尔玛超市的数据库里有很多张表格，记录着各个商品的交易记录。超市里销售一种运动饮料，我们不妨称之为红牛。数据库中有一张表A，记录了红牛在一年的各个月份的销售额；还有一张表B，记录了红牛每个月在美国各个州的销售额：；甚至还有一张表C，记录了这家饮料公司在每个州对红牛饮料的宣传资金投入；甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。好，最后问题来了，请根据以上数据分析红牛在宣传资金不超过三百万的情况下，什么季节，什么天气，美国哪个州最好卖？凭借我们的经验，可能会得出，夏季的晴天，在美国的佛罗里达，最好卖，而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的，但决策者想要看到的是确凿的数据结论，而不是“可能”这样的字眼。科学是不相信直觉的，如果我们人工进行手动分析，会发现这个要考虑的维度实在太多了，根本无法下手，何况这才四五个维度，要是更多了怎么办？OLAP就是为了解决这样的问题诞生的，但糟糕的是，传统数据库是无法满足OLAP所需要的数据信息的。2.3 数据仓库概念
2.3.1 概述
数据库的大规模应用，使得信息行业的数据爆炸式的增长，为了研究数据之间的关系，挖掘数据隐藏的价值，人们越来越多的需要使用OLAP来为决策者进行分析，探究一些深层次的关系和信息。但很显然，不同的数据库之间根本做不到数据共享，就算同一家数据库公司，数据库之间的集成也存在非常大的挑战（最主要的问题是庞大的数据如何有效合并、存储）。1988年，为解决企业的数据集成问题，IBM（卧槽，又是IBM）的两位研究员（Barry Devlin和Paul Murphy）创造性地提出了一个新的术语：数据仓库（Data Warehouse）。看到这里读者朋友们可能要问了，然后呢？然后…然后就没然后了。就在这个创世纪的术语诞生了之后，IBM就哑火了，只是将这个名词作为市场宣传的花哨概念，并没有在技术领域有什么实质性的研究和突破（可悲我大IBM=。=）。然而，尽管IBM不为所动，其他企业却在加紧对数据仓库的研究和开发，大家都想在这个领域寻找到第一桶金。终于，到了1992年，后来被誉为“数据仓库之父”的比尔 恩门（Bill Inmon）给出了数据仓库的定义，二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理中的决策制定。对于数据仓库的概念我们可以从两个层次予以理解：首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。我们可以不用管这个定义，简单的理解，其实就是我们为了进行OLAP，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心，但是我们要知道，原来各个数据孤岛中的数据，可能会在物理位置（比如沃尔玛在各个州可能都有自己的数据中心）、存储格式（比如月份是数值类型，但但天气可能是字符类型）、商业平台（不同数据库可能用的是Oracle数据库，有的是微软SQL Server数据库）、编写的语言（Java或者Scale等）等等各个方面完全不同，数据仓库要做的工作就是将他们按照所需要的格式提取出来，再进行必要的转换（统一数据格式）、清洗（去掉无效或者不需要的数据）等，最后装载进数据仓库（我们所说的ETL工具就是用来干这个的）。这样，拿我们上面红牛的例子来说，所有的信息就统一放在了数据仓库中了。自从数据仓库出现之后，信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统，其实就是我们现在说的商务智能（Business Intelligence）即BI。可以这么说，数据仓库为OLAP解决了数据来源问题，数据仓库和OLAP互相促进发展，进一步驱动了商务智能的成熟，但真正将商务智能赋予“智能”的，正是我们现在热谈的下一代技术：数据挖掘。2.3.2 数据仓库特点
集成性
集成性是指数据仓库会将不同源数据库中的数据汇总到一起；具体来说，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。企业范围
数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；历史性
较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；时变性
时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。2.3.3 数据仓库与BI
数据仓库平台逐步从BI报表为主到分析为主、到预测为主、再到操作智能为目标。2.3.4 数据仓库系统作用和定位
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合，为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息（或知识），并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具； 是主要用于历史性、综合性和深层次数据分析； 数据来源是ERP（例:SAP）系统或其他业务系统； 能够提供灵活、直观、简洁和易于操作的多维查询分析; 不是日常交易操作系统，不能直接产生交易数据。
2.3.5 数据仓库能提供什么
2.4 数据仓库组件
数据仓库的核心组件有四个：业务系统各源数据库，ETL，数据仓库，前端应用。如下图所示：业务系统
业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；ETL
数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为'目标系统'。ETL分别代表：提取extraction
表示从操作型数据库搜集指定数据转换transformation
表示将数据转化为指定格式，并进行数据清洗保证数据质量加载load
加载过程表示将转换过后满足指定格式的数据加载进数据仓库。前端应用
和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用。数据仓库系统除了包含分析产品本身之外，还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。
2.5 数据仓库开发流程
2.5.1 概述
数据仓库的开发流程和数据库的比较相似，因此本文仅就其中区别进行分析。下图为数据仓库的开发流程：2.5.2 数据仓库需求
需求搜集是所有环节中最重要的一步，吃透了用户需求，往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等。通常来说，需求都会通过ER图来表示(参考数据库需求与ER建模)，并和各业务方讨论搜集得到，最终整理成文档。要特别强调的一点是数据仓库系统开发需求阶段过程是循环迭代式的，一开始的需求集并不大，但随着项目的进展，需求会越来越多。而且不论是以上哪个阶段发生了需求变动，整个流程都需要重新走一遍，决不允许隐式变更需求。比如为一个学生选课系统进行ER建模，得到如下结果：2.5.3 数据仓库建模
也就是逻辑模型建模，可参考第二篇：数据库关系建模ER建模环节完成后，需求就被描述成了ER图。之后，便可根据这个ER图设计相应的关系表了。但从ER图到具体关系表的建立还需要经过两个步骤：1. 逻辑模型设计 2. 物理模型设计。其中前者将ER图映射为逻辑意义上的关系表，后者则映射为物理意义上的关系表。逻辑意义上的关系表可以理解为单纯意义上的关系表，它不涉及到表中字段数据类型，索引信息，触发器等等细节信息。概念模型 VS 逻辑模型
我们首先可以认为【概念模型建模和ER建模，需求可视化】表达的是一个意思。在这个环节中，数据开发人员绘制ER图，并和项目各方人员协同需求，达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱，甚至不懂开发，因此ER图必须清晰明了，不能涉及到过多的技术细节，比如：要给多对多联系/多值属性等多建一张表，要设置外码，各种复合主码等，它们应当对非开发人员透明。而且ER图中每个属性只会出现一次，减少了蕴含的信息量，是更好的交流和文档化工具。在ER图绘制完毕之后，才开始将它映射为关系表。这个映射的过程，就叫做逻辑模型建模或者关系建模。还有，ER模型所蕴含的信息，也没有全部被逻辑模型包含。比如联系的自定义基数约束，比如实体的复合属性，派生属性，用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模，甚至前端开发)中是都会用到的，不能认为ER模型转换到逻辑模型后就可以扔一边了。逻辑模型VS物理模型
逻辑模型设计好后，就可以开始着手数据仓库的物理实现了，他也被称为物理模型建模，这个阶段不但需要参照逻辑模型，还应当参照ER图。2.5.4 数据仓库实现
这一步的本质就是在空的数据仓库里实现2种前面创建的关系模型，一般通过使用SQL或者提供的前端工具实现。2.5.5 开发前端应用程序
前端应用开发在需求搜集好了之后就开始进行，主要有网站、APP等前端形式。另外前端程序的实际实现涉及到和数据仓库之间交互，因此这一步的最终完成在数据库建模之后。2.5.6 ETL工程
较之数据库系统开发流程，数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL专家。2.5.7 数据仓库部署
顾名思义，这一步就是部署数据库系统的软硬件环境。数据库部署往往还包含将初始数据填入数据库中的意思。对于云数据仓库，这一步就叫'数据上云'。2.5.8 数据仓库使用
这一步没啥多讲的，就再讲一个有关的故事吧。同样是在A公司，有一次某政企私有云项目完成后，我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大，认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF，更拒绝MR编程接口，只要SQL和图形界面操作方式。一开始我对政企的这种行为有点看不起，但后来我想，就是因为有这群挑剔的用户，才使得A公司云产品的易用性如此强大，从而占领国内云计算的大部分市场。用户的需求才是技术的唯一试金石。2.5.9 数据库管理和维护
严格来讲，这部分不算开发流程，属于数据库系统开发完成后的工作。2.6 数据仓库系统管理
数据仓库系统发行后，控制权便从数据仓库设计、实现、部署的团队移交给了数据仓库管理员，并由他们来对系统进行管理，涵盖了确保一个已经部署的数据仓库系统正确运行的各种行为。为了实现这一目标，具体包含以下范畴：2.7 数据质量体系
数据仓库系统需要重视数据质量问题。用一句话概括，数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说，数据质量包含以下几大指标：准确性
准确性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen错误的录入成了muc hen，就应该弹出警告语；唯一性（视情况而定）
唯一性要求数据不能被重复录入，或者不能有两个几乎相同的关系。比如张三李四在不同业务环境下分别建立了近乎相同的关系，这时应将这两个关系合并；完整性
完整性要求进行数据搜集时，需求数据的被描述程度要高。比如一个用户的购买记录中，必然要有支付金额这个属性；规则验证。一致性
一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。比如某关系中昨天存货量字段+当天进货量字段-当天销售量字段等于当天存货量就可能是数据质量有问题；及时性
及时性要求数据库系统中的数据'保鲜'。比如当天的购买记录当天就要入库；统一性
统一性要求数据格式统一。比如nike这个品牌，不能有的字段描述为'耐克'，而有的字段又是'奈克'；小结
数据质量和数据具体意义有很大相关性，因此无法单凭理论来保证。且由于具体业务及真实世界的复杂性，数据质量问题必然会存在，不可能完全预防得了。因此很多公司都提供了数据质量工程服务/软件，用来识别和校正数据库系统中的各种数据质量问题。企业范围还是部门范围 先建立数据仓库还是数据集市 建立领航系统还是直接实施 数据集市是否相互独立
4.1 概述
Pentaho首席技术官James Dixon创造了“数据湖”一词。它把数据集市描述成一瓶水（清洗过的，包装过的和结构化易于使用的）。而数据湖更像是在自然状态下的水，数据流从源系统流向这个湖。用户可以在数据湖里校验，取样或完全的使用数据。这个也是一个不精确的定义。数据湖还有以下特点：从源系统导入所有的数据，没有数据流失。 数据存储时没有经过转换或只是简单的处理。 数据转换和定义schema 用于满足分析需求。
4.2 数据湖定义
4.2.1 维基百科对数据湖的定义
4.2.2 AWS对数据湖的定义
AWS定义数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。4.2.3 微软对数据湖的定义
微软的定义就更加模糊了，并没有明确给出什么是Data Lake，而是取巧的将数据湖的功能作为定义，数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。Azure Data Lake includes all the capabilities required to make it easy for developers, data scientists, and analysts to store data of any size, shape, and speed, and do all types of processing and analytics across platforms and languages. It removes the complexities of ingesting and storing all of your data while making it faster to get up and running with batch, streaming, and interactive analytics. Azure Data Lake works with existing IT investments for identity, management, and security for simplified data management and governance. It also integrates seamlessly with operational stores and data warehouses so you can extend current data applications. We’ve drawn on the experience of working with enterprise customers and running some of the largest scale processing and analytics in the world for Microsoft businesses like Office 365, Xbox Live, Azure, Windows, Bing, and Skype. Azure Data Lake solves many of the productivity and scalability challenges that prevent you from maximizing the value of your data assets with a service that’s ready to meet your current and future business needs.Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力，这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据，并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时，消除了数据采集和存储的复杂性，同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作，保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成，帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验，并且在微软一些业务中支持了大规模处理和分析场景，包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战，作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。4.2.4 数据湖定义小结
数据湖需要提供足够用的数据存储能力 这个存储保存了一个企业/组织中的所有数据。数据湖可以存储海量的任意类型的数据 包括结构化、半结构化和非结构化数据。数据湖中的数据是原始数据，是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。数据湖需要具备完善的数据管理能力（完善的元数据） 可以管理各类数据相关的要素，包括数据源、数据格式、连接信息、数据schema、权限管理等。数据湖需要具备多样化的分析能力 包括但不限于批处理、流式计算、交互式分析以及机器学习；同时，还需要提供一定的任务调度和管理能力。数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据，还需要能够保存各类分析处理的中间结果，并完整的记录数据的分析处理过程，能帮助用户完整详细追溯任意一条数据的产生过程。4.3 数据湖的处理架构
4.3.1 概述
ODS
数据从不同的数据库转移到单一的存储区域，如云存储服务(如Amazon S3、ADLS)、HDFS。数据仓库
虽然可以在Hadoop和云存储上直接执行SQL查询，但是这些系统的设计目的并不是提供交互性能。因此，数据的子集通常被加载到关系数据仓库或MPP数据库中，也就是构建数据仓库。数据集市
为了在大型数据集上提供交互性能，必须通过在OLAP系统中构建多维数据集或在数据仓库中构建物化聚合表对数据进行预聚合这种多层体系架构带来了许多挑战。例如：灵活性，比如数据源的变化或新的数据需求，必须重新访问数据仓库每一层，以确保后续应用人员来使用，可能会花费较长的实施周期。 复杂性，数据分析人员必须了解所有存储数据的查询语法，增加了不必要的复杂性。 技术成本，该架构需要广泛的定制ETL开发、DBA专业知识和数据工程来满足业务中不断发展的数据需求。 基础设施成本，该架构需要大量的专有技术，并且通常会导致存储在不同系统中的数据产生许多副本。 数据治理，该架构如果血缘关系搞的不好，便使得跟踪、维护变得非常困难。 数据及时性，在ETL的过程中需要时间，所以一般数据是T-1的统计汇总。
4.3.2 第一阶段-以Hadoop为代表的离线数据处理基础设施
数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构，我们先来看看大数据基础设施架构的演进过程。如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施。4.3.3 第二阶段：lambda架构
随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出，如下图所示。4.3.4 第三阶段：Kappa架构
Lambda架构虽然解决了应用读取数据的统一性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。4.3.5 大数据基础设施架构小结
综上，从传统的hadoop架构往lambda架构，从lambda架构往Kappa架构的演进，大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力，大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中，除了关系型数据库依托于各个独立的业务系统；其余的数据，几乎都被考虑纳入大数据平台来进行统一的处理。然而，目前的大数据平台基础架构，都将视角锁定在了存储和计算，而忽略了对于数据的资产化管理，这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。大数据基础架构的演进，其实反应了一点：在企业/组织内部，数据是一类重要资产已经成为了共识；为了更好的利用数据，企业/组织需要对数据资产进行如下操作：进行长期的原样存储，以便可回溯重放原始数据进行有效管理与集中治理；提供多模式的计算能力满足处理需求；以及面向业务，提供统一的数据视图、数据模型与数据处理结果。数据湖就是在这个大背景下产生的，除了有大数据平台所拥有的各类基础能力之外，数据湖更强调对于数据的管理、治理和资产化能力。落到具体的实现上，数据湖需要包括一系列的数据管理组件，包括：数据接入； 数据搬迁； 数据治理； 数据质量管理； 资产目录； 访问控制； 任务管理； 任务编排； 元数据管理等。
更强大的数据接入能力。
数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。更强大的数据管理能力。
管理能力具体又可分为基本管理能力和扩展管理能力：基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的，后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。 扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务，通常情况下，数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力，定制的系统/模块可以通过读取数据湖的相关元数据，来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题，一般情况下，数据湖系统不会直接提供相关功能，但是会开放各类接口或者元数据，供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
可共享的元数据。
数据湖中的各类计算引擎会与数据湖中的数据深度融合，而融合的基础就是数据湖的元数据。好的数据湖系统，计算引擎在处理数据时，能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息，然后直接进行数据处理，而无需进行人工/编程干预。更进一步，好的数据湖系统还可以对数据湖中的数据进行访问控制，控制的力度可以做到“库表列行”等不同级别。还有一点应该指出的是，前面数据湖系统的参考架构图的集中式存储更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。我们可以再切换到数据维度，从数据生命周期的视角来看待数据湖对于数据的处理方式，数据在数据湖中的整个生命周期如下图所示。理论上，一个管理完善的数据湖中的数据会永久的保留原始数据，同时过程数据会不断的完善、演化，以满足业务的需要。4.4 数据湖能给企业带来多种能力
数据湖能给企业带来多种能力，例如，能实现数据的集中式管理，在此之上，企业能挖掘出很多之前所不具备的能力。另外，数据湖结合先进的数据科学与机器学习技术，能帮助企业构建更多优化后的运营模型，也能为企业提供其他能力，如预测分析、推荐模型等，这些模型能刺激企业能力的后续增长。数据湖能从以下方面帮助到企业：实现数据治理（data governance）；通过应用机器学习与人工智能技术实现商业智能； 预测分析，如领域特定的推荐引擎； 信息追踪与一致性保障； 根据对历史的分析生成新的数据维度； 有一个集中式的能存储所有企业数据的数据中心，有利于实现一个针对数据传输优化的数据服务； 帮助组织或企业做出更多灵活的关于企业增长的决策。
4.5 数据湖与数据仓库区别
4.5.2 数据湖保留全部的数据
存储范围
数据仓库开发期间，大量的时间花费在分析数据源，理解商业处理和描述数据。结果就是为报表设计高结构化的数据模型。这一过程大部分的工作就是来决定数据应不应该导入数据仓库。通常情况下，如果数据不能满足指定的问题，就不会导入到数据仓库。这么做是为了简化数据模型和节省数据存储空间。相反，数据湖保留所有的数据。不仅仅是当前正在使用的数据，甚至不被用到的数据也会导进来。数据会一直被保存所有我们可以回到任何时间点来做分析。因为数据湖使用的硬件与数据仓库的使用的不同，使这种方法成为了可能。现成的服务器与便宜的存储相结合，使数据湖扩展到TB级和PB级非常经济。存储来源
数据仓库主要存储来自运营系统的大量数据而数据湖则存储来自更多来源的数据，包括来自企业的运营系统和其他来源的各种原始数据资产集。4.5.3 数据湖支持所有数据类型
在储存方面上，数据湖中数据为非结构化的，所有数据都保持原始形式，并且仅在分析时再进行转换。数据仓库一般由从事务系统中提取的数据组成，并由定量度量和描述它们的属性组成。诸如Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现，但是消费和存储它们可能是昂贵和困难的。数据湖方法包含这些非传统数据类型。在数据湖中，我们保留所有数据，而不考虑源和结构。我们保持它的原始形式，并且只有在我们准备好使用它时才会对其进行转换。这种方法被称为“读时模式”。数据仓库则是捕获结构化数据并将其按模式组织。4.5.4 适用人群
由于数据湖中的数据可能不准确，并且可能来自企业运营系统之外的来源，因此不是很适合普通的业务分析用户;数据湖更适合数据科学家和其他数据分析专家，使用他们需要的非常庞大和多样化的数据集。其他用户则可以使用更为结构化的数据视图如数据仓库来提供他们使用的数据，数据仓库非常适用于月度报告等操作用途，因为它具有高度结构化。4.5.5 数据湖很容易适应变化
关于数据仓库的主要抱怨之一是需要多长时间来改变它们。在开发过程中花费大量时间来获得仓库的结构。一个好的仓库设计可以适应变化，但由于数据加载过程的复杂性以及为简化分析和报告所做的工作，这些更改必然会消耗一些开发人员资源并需要一些时间。许多业务问题都迫不及待地让数据仓库团队适应他们的系统来回答问题。日益增长的对更快答案的需求促成了自助式商业智能的概念。另一方面，在数据湖中，由于所有数据都以其原始形式存储，并且始终可供需要使用它的人访问，因此用户有权超越仓库结构以新颖方式探索数据并回答它们问题在他们的步伐。如果一个探索的结果被证明是有用的并且有重复的愿望，那么可以应用更正式的模式，并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的受众。如果确定结果无用，则可以丢弃该结果，并且不会对数据结构进行任何更改，也不会消耗开发资源。所以，在架构方面：数据湖通常在存储数据之后定义架构，使用较少的初始工作并提供更大的灵活性。在数据仓库中存储数据之前定义架构。4.5.6 数据湖支持快速洞察数据
4.6 数据湖和数据仓库理解误区
误解一：数据仓库和数据湖二者在架构上只能二选一
误解二：相对于数据湖，数据仓库更有名更受欢迎
误解三：数据仓库易于使用，而数据湖却很复杂
4.7 数据湖建设的基本过程
个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施，完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性，例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等，无一不是为了更好的贴近业务，更好的方便客户使用。数据湖所强调的一些基本的技术特性，例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等，也是为了满足业务需求，并且给业务方提供最具性价比的TCO。数据湖的建设过程应该与业务紧密结合；但是数据湖的建设过程与传统的数据仓库，甚至是大热的数据中台应该是有所区别的。区别在于，数据湖应该以一种更敏捷的方式去构建，“边建边用，边用边治理”。为了更好的理解数据湖建设的敏捷性，我们先来看一下传统数仓的构建过程。业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式，分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了，不然可以再写出几百页，这里只简单阐述基本思想。1）Inmon提出自下而上（EDW-DM）的数据仓库建设模式，即操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层；ODS层中的数据，根据预先设计好的EDW（企业级数据仓库）范式进行加工处理，然后进入到EDW。EDW一般是企业/组织的通用数据模型，不方便上层应用直接做数据分析；因此，各个业务部门会再次根据自己的需要，从EDW中处理出数据集市层（DM）。优势：易于维护，高度集成；劣势：结构一旦确定，灵活性不足，且为了适应业务，部署周期较长。此类方式构造的数仓，适合于比较成熟稳定的业务，例如金融。2）KimBall提出自顶而下（DM-DW）的数据架构，通过将操作型或事务型系统的数据源，抽取或加载到ODS层；然后通过ODS的数据，利用维度建模方法建设多维主题数据集市（DM）。各个DM，通过一致性的维度联系在一起，最终形成企业/组织通用的数据仓库。优势：构建迅速，最快的看到投资回报率，敏捷灵活；劣势：作为企业资源不太好维护，结构复杂，数据集市集成困难。常应用于中小企业或互联网行业。其实上述只是一个理论上的过程，其实无论是先构造EDW，还是先构造DM，都离不开对于数据的摸底，以及在数仓构建之前的数据模型的设计，包括当前大热的“数据中台”，都逃不出下图所示的基本建设过程。1） 数据摸底。
对于一个企业/组织而言，在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等。在这个阶段一个隐含的重要工作是借助数据摸底工作，进一步梳理企业的组织结构，明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础。2） 模型抽象。
针对企业/组织的业务特点梳理归类各类数据，对数据进行领域划分，形成数据管理的元数据，同时基于元数据，构建通用的数据模型。3） 数据接入。
根据第一步的摸排结果，确定要接入的数据源。根据数据源，确定所必须的数据接入技术能力，完成数据接入技术选型，接入的数据至少包括：数据源元数据、原始数据元数据、原始数据。各类数据按照第二步形成的结果，分类存放。4） 融合治理。
简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理，形成各类中间数据/结果数据，并妥善管理保存。数据湖应该具备完善的数据开发、任务管理、任务调度的能力，详细记录数据的处理过程。在治理的过程中，会需要更多的数据模型和指标模型。5） 业务支撑。
在通用模型基础上，各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务。上述过程，对于一个快速成长的互联网企业来说，太重了，很多情况下是无法落地的，最现实的问题就是第二步模型抽象，很多情况下，业务是在试错、在探索，根本不清楚未来的方向在哪里，也就根本不可能提炼出通用的数据模型；没有数据模型，后面的一切操作也就无从谈起，这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。数据湖应该是一种更为“敏捷”的构建方式，我们建议采用如下步骤来构建数据湖。1） 数据摸底。
依然需要摸清楚数据的基本情况，包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是，也就需要做这么多了。数据湖是对原始数据做全量保存，因此无需事先进行深层次的设计。2） 技术选型。
根据数据摸底的情况，确定数据湖建设的技术选型。事实上，这一步也非常的简单，因为关于数据湖的技术选型，业界有很多的通行的做法，基本原则个人建议有三个：“计算与存储分离”、“弹性”、“独立扩展”。建议的存储选型是分布式对象存储系统（如S3/OSS/OBS）；计算引擎上建议重点考虑批处理需求和SQL处理能力，因为在实践中，这两类能力是数据处理的关键，关于流计算引擎后面会再讨论一下。无论是计算还是存储，建议优先考虑serverless的形式；后续可以在应用中逐步演进，真的需要独立资源池了，再考虑构建专属集群。3） 数据接入。
确定要接入的数据源，完成数据的全量抽取与增量接入。4） 应用治理。
这一步是数据湖的关键，我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看，数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手，在应用中明确需求，在数据ETL的过程中，逐步形成业务可使用的数据；同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储，强调对数据的探索式分析与应用，但这绝对不是说数据湖不需要数据模型；恰恰相反，对业务的理解与抽象，将极大的推动数据湖的发展与应用，数据湖技术使得数据的处理与建模，保留了极大的敏捷性，能快速适应业务的发展与变化。从技术视角来看，数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用，需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。在计算能力上，目前主流的数据湖方案都支持SQL和可编程的批处理两种模式（对机器学习的支持，可以采用Spark或者Flink的内置能力）；在处理范式上，几乎都采用基于有向无环图的工作流的模式，并提供了对应的集成开发环境。对于流式计算的支持，目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前，我们先对流计算做一个分类：1） 模式一：实时模式。
这种流计算模式相当于对数据采用“来一条处理一条”/“微批”的方式进行处理；多见于在线业务，如风控、推荐、预警等。2） 模式二：类流式。
这种模式需要获取指定时间点之后变化的数据/读取某一个版本的数据/读取当前的最新数据等，是一种类流式的模式；多见于数据探索类应用，如分析某一时间段内的日活、留存、转化等。二者的本质不同在于，模式一处理数据时，数据往往还没有存储到数据湖中，仅仅是在网路/内存中流动；模式二处理数据时，数据已经存储到数据湖中了。综上，我个人建议采用如下图模式：4.8 主流厂商数据湖解决方案
4.8.1 AWS数据湖解决方案
数据流入
数据流入是整个数据湖构建的起始，包括元数据的流入和业务数据流入两个部分。元数据流入包括数据源创建、元数据抓取两步，最终会形成数据资源目录，并生成对应的安全设置与访问控制策略。解决方案提供专门的组件，获取外部数据源的相关元信息，该组件能连接外部数据源、检测数据格式和模式（schema），并在对应的数据资源目录中创建属于数据湖的元数据。业务数据的流入是通过ETL来完成的。在具体的产品形式上，元数据抓取、ETL和数据准备AWS将其单独抽象出来，形成了一个产品叫AWS GLUE。AWS GLUE与AWS Lake Formation共享同一个数据资源目录，在AWS GLUE官网文档上明确指出：“Each AWS account has one AWS Glue Data Catalog per AWS region”。对于异构数据源的支持。AWS提供的数据湖解决方案，支持S3、AWS关系型数据库、AWS NoSQL数据库，AWS利用GLUE、EMR、Athena等组件支持数据的自由流动。数据沉淀
采用Amazon S3作为整个数据湖的集中存储，按需扩展/按使用量付费。数据计算
整个解决方案利用AWS GLUE来进行基本的数据处理。GLUE基本的计算形式是各类批处理模式的ETL任务，任务的出发方式分为手动触发、定时触发、事件触发三种。不得不说，AWS的各类服务在生态上实现的非常好，事件触发模式上，可以利用AWS Lambda进行扩展开发，同时触发一个或多个任务，极大的提升了任务触发的定制开发能力；同时，各类ETL任务，可以通过CloudWatch进行很好的监控。数据应用。
在提供基本的批处理计算模式之外，AWS通过各类外部计算引擎，来提供丰富的计算模式支持，例如通过Athena/Redshift来提供基于SQL的交互式批处理能力；通过EMR来提供各类基于Spark的计算能力，包括Spark能提供的流计算能力和机器学习能力。权限管理
AWS的数据湖解决方案通过Lake Formation来提供相对完善的权限管理，粒度包括“库-表-列”。但是，有一点例外的是，GLUE访问Lake Formation时，粒度只有“库-表”两级；这也从另一个侧面说明，GLUE和Lake Formation的集成是更为紧密的，GLUE对于Lake Formation中的数据有更大的访问权限。Lake Formation的权限进一步可以细分为数据资源目录访问权限和底层数据访问权限，分别对应元数据与实际存储的数据。实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限：数据存取权限类似于数据库中对于库表的访问权限数据存储权限则进一步细化了对于S3中具体目录的访问权限（分为显示和隐式两种）。如下图所示，用户A在只有数据存取的权限下，无法创建位于S3指定bucket下的表。个人认为这进一步体现了数据湖需要支持各种不同的存储引擎，未来的数据湖可能不只S3/OSS/OBS/HDFS一类核心存储，可能根据应用的访问需求，纳入更多类型的存储引擎，例如，S3存储原始数据，NoSQL存储处理过后适合以“键值”模式访问的数据，OLAP引擎存储需要实时出各类报表/adhoc查询的数据。虽然当前各类材料都在强调数据湖与数据仓库的不同；但是，从本质上，数据湖更应该是一类融合的数据管理思想的具体实现，“湖仓一体化”也很可能是未来的一个发展趋势。综上，AWS数据湖方案成熟度高，特别是元数据管理、权限管理上考虑充分，打通了异构数据源与各类计算引擎的上下游关系，让数据能够自由“移动”起来。在流计算和机器学习上，AWS的解决方案也比较完善：流计算方面AWS推出了专门的流计算组件Kinesis，Kinesis中的Kinesis data Firehose服务可以创建一个完全被托管的数据分发服务，通过Kinesis data Stream实时处理的数据，可以借助Firehose方便的写入S3中，并支持相应的格式转换，如将JSON转换成Parquet格式。AWS整个方案最牛的地方还在与Kinesis可以访问GLUE中的元数据，这一点充分体现了AWS数据湖解决方案在生态上的完备性。同样，在机器学习方面，AWS提供了SageMaker服务，SageMaker可以读取S3中的训练数据，并将训练好的模型回写至S3中。但是，有一点需要指出的是，在AWS的数据湖解决方案中，流计算和机器学习并不是固定捆绑的，只是作为计算能力扩展，能方便的集成。最后，让我们回到数据湖组件参考架构，看看AWS的数据湖解决方案的组件覆盖情况，参见下图 AWS 数据湖解决方案在参考架构中的映射。
4.8.2 华为数据湖解决方案
4.8.3 阿里云数据湖解决方案
阿里云上数据类产品众多，因为本人目前在数据BU，所以本节方案将关注在如何使用数据库BU的产品来构建数据湖，其他云上产品会略有涉及。阿里云的基于数据库产品的数据湖解决方案更加聚焦，主打数据湖分析和联邦分析两个场景。阿里云数据湖解决方案如下图所示。4.8.4 Microsoft Azure数据湖解决方案
Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层，如下图所示（来自Azure官网）。存储层是基于Azure object Storage构建的，依然是对结构化、半结构化和非结构化数据提供支撑。接口层为WebHDFS，比较特别的是在Azure object Storage实现了HDFS的接口，Azure把这个能力称为“数据湖存储上的多协议存取”。在资源调度上，Azure基于YARN实现。计算引擎上，Azure提供了U-SQL、hadoop和Spark等多种处理引擎。4.8.5 小结
本文所讨论的是数据湖的解决方案，不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、数据计算、数据管理、应用生态几个方面，简单做了一个类似下表的总结。4.9 典型的数据湖应用案例
4.9.1 广告数据分析
近年来，流量获取的成本就越来越高，线上渠道获客成本的成倍增长让各行各业都面临着严峻的挑战。在互联网广告成本不断攀升的大背景下，以花钱买流量拉新为主要的经营策略必然行不通了。流量前端的优化已成强弩之末，利用数据工具提高流量到站后的目标转化，精细化运营广告投放的各个环节，才是改变现状更为直接有效的方式。说到底，要提高广告流量的转化率，必须依靠大数据分析。为了能够提供更多的决策支撑依据，需要采取更多的埋点数据的收集和分析，包括但不限于渠道、投放时间、投放人群，以点击率为数据指标进行数据分析，从而给出更好的、更迅速的方案和建议，实现高效率高产出。因此，面对广告投放领域多维度、多媒体、多广告位等结构化、半结构化和非结构化数据采集、存储、分析和决策建议等要求，数据湖分析产品解决方案在广告主或者发布商进行新一代技术选型中上受到了很热烈的青睐。DG是一家全球领先的企业国际化智能营销服务商，基于先进的广告技术、大数据和运营能力，为客户提供全球高质量用户获取及流量变现服务。DG从成立之初就决定以公有云为基础来构建其IT基础设施，最初DG选择了AWS云平台，主要将其广告数据在S3中以数据湖的形态进行存放，通过Athena进行交互式分析。然而随着互联网广告的飞速发展，广告行业带来了几大挑战，移动广告的发布与追踪系统必须解决几个关键问题：1） 并发性与峰值问题。在广告行业，流量高峰时常出现，瞬间的点击量可能达到数万，甚至数十万，这就要求系统具备非常好的可扩展性以快速响应和处理每一次点击2） 如何实现对海量数据的实时分析。为了监控广告投放效果，系统需要实时对用户的每一次点击和激活数据进行分析，同时把相关数据传输到下游的媒体；3） 平台的数据量在急剧增长，每天的业务日志数据在持续的产生和上传，曝光、点击、推送的数据在持续处理，每天新增的数据量已经在10-50TB左右，对整个数据处理系统提出了更高的要求。如何高效地完成对广告数据的离线/近实时统计，按照广告客户的维度要求进行聚合分析。针对上述三点业务挑战，同时DG这个客户日增量数据正在急剧变大（当前日数据扫描量达到100+TB），继续在AWS平台使用遇到Athena读取S3数据带宽瓶颈、数据分析滞后时间越来越长、为应对数据和分析需求增长而急剧攀升的投入成本等，经过认真、仔细的测试和分析，最终决定从AWS云平台全量搬站到阿里云平台，新架构图如下：4.9.2 游戏运营分析
数据湖是一类TCO表现极其优秀的大数据基础设施。对于很多快速增长的游戏公司而言，一个爆款游戏，往往在短期内相关数据增长极快；同时，公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配；此时，呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问题的技术选择。YJ是一家高速成长的游戏公司，公司希望能依托相关用户行为数据进行深入分析，指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大，玩家对于品质的要求越来越高，游戏项目的生命周期越来越短，直接影响项目的投入产出比，通过数据运营则可以有效的延长项目的生命周期，对各个阶段的业务走向进行精准把控。而随着流量成本的日益上升，如何构建经济、高效的精细化数据运营体系，以更好的支撑业务发展，也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施，如何选择这类基础支撑设施，是公司技术决策者需要思考的问题。思考的出发点包括：1） 要有足够的弹性。对于游戏而言，往往就是短时间爆发，数据量激增；因此，能否适应数据的爆发性增长，满足弹性需求是一个重点考量的点；无论是计算还是存储，都需要具备足够的弹性。2） 要有足够的性价比。对于用户行为数据，往往需要拉到一个很长的周期去分析去对比，比如留存率，不少情况下需要考虑90天甚至180天客户的留存率；因此，如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。3） 要有够用的分析能力，且具备可扩展性。许多情况下，用户行为体现在埋点数据中，埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析；因此，在数据分析上，至少需要有大数据的ETL能力、异构数据源的接入能力和复杂分析的建模能力。4） 要与公司现有技术栈相匹配，且后续利于招聘。对于YJ，其在技术选型的时候一个重要点就是其技术人员的技术栈，YJ的技术团队大部分只熟悉传统的数据库开发，即MySQL；并且人手紧张，做数据运营分析的技术人员只有1个，短时间内根本没有能力独立构建大数据分析的基础设施。从YJ的角度出发，最好绝大多数分析能够通过SQL完成；并且在招聘市场上，SQL开发人员的数量也远高于大数据开发工程师的数量。针对客户的情况，我们帮助客户对现有方案做了改造。图18. 改造前的方案改造前，客户所有的结构化数据都在一个高规格的MySQL里面；而玩家行为数据则是通过LogTail采集至日志服务（SLS）中，然后从日志服务中分别投递到OSS和ES里。这个架构的问题在于：1）行为数据和结构化数据完全割裂，无法联动分析；2）对于行为数据智能提供检索功能，无法做深层次的挖掘分析；3）OSS仅仅作为数据存储资源使用，并没有挖掘出足够的数据价值。事实上，我们分析客户现存架构其实已经具备了数据湖的雏形：全量数据已经在OSS中保存下来了，现在需要进一步补齐客户对于OSS中的数据的分析能力。而且数据湖基于SQL的数据处理模式也满足客户对于开发技术栈的需求。综上，我们对客户的架构做了如下调整，帮助客户构建了数据湖。
图20. YM智能数据服务SaaS模式示意平台方提供多端SDK供用户（商家提供网页、APP、小程序等多种接入形式）接入各类埋点数据，平台方以SaaS的形式提供统一的数据接入服务和数据分析服务。商家通过访问各类数据分析服务来进行更细粒度的埋点数据分析，完成行为统计、客户画像、客户圈选、广告投放监测等基本分析功能。然而，这种SaaS模式下，会存在一定的问题：1） 由于商家类型和需求的多样化，平台提供SaaS类分析功能很难覆盖所有类型的商家，无法满足商家的定制化需求；如有些商家关注销量，有些关注客户运营，有些关注成本优化，很难满足所有的需求。2） 对于一些高级分析功能，如依赖于自定义标签的客户圈选、客户自定义扩展等功能，统一的数据分析服务无法满足的；特别是一些自定义的标签依赖于商家自定义的算法，无法满足客户的高级分析需求。3） 数据的资产化管理需求。在大数据时代，数据是一个企业/组织的资产已经成为了大家的共识，如何能让属于商家的数据合理、长期的沉淀下来，也是SaaS服务需要考虑的事情。综上，我们在上图的基本模式上引入了数据湖模式，让数据湖作为商家沉淀数据、产出模型、分析运营的基础支撑设施。引入数据湖后的SaaS数据智能服务模式如下。
4.10 LakeHouse
4.11 数据湖总结
数据湖作为新一代大数据分析处理的基础设施，需要超越传统的大数据平台。个人认为目前在以下方面，是数据湖解决方案未来可能的发展方向。云原生架构
关于什么是云原生架构，众说纷纭，很难找到统一的定义。但是具体到数据湖这个场景，个人认为就是以下三点特征：存储和计算分离，计算能力和存储能力均可独立扩展；多模态计算引擎支持，SQL、批处理、流式计算、机器学习等；提供serverless态服务，确保足够的弹性以及支持按需付费。足够用的数据管理能力
数据湖需要提供更为强大的数据管理能力，包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。大数据的能力，数据库的体验
目前绝大多数数据分析人员都只有数据库的使用经验，大数据平台的能力虽强，但是对于用户来说并不友好，数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配，而不是花大量的时间精力去学习大数据平台的开发。数据湖要想快速发展，如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心，如何将数据湖的能力通过SQL的形式释放出来，是未来的一个主要方向。完善的数据集成与数据开发能力
对各种异构数据源的管理与支持，对异构数据的全量/增量迁移支持，对各种数据格式的支持都是需要不断完善的方向。同时，需要具备一个完备的、可视化的、可扩展的集成开发环境。与业务的深度融合与集成
典型数据湖架构的构成基本已经成为了业界共识：分布式对象存储+多模态计算引擎+数据管理。决定数据湖方案是否胜出的关键恰恰在于数据管理，无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理，都离不开与业务的适配和集成；未来，会有越来越多的行业数据湖解决方案涌现出来，与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法，可能是未来数据湖领域差异化竞争的一个关键点。5.1 基础概念
5.1.1 产生的背景
企业在过去信息化的历程中形成了大量生产经营及专业业务应用成果，同时也累积了大量的企业数据资产。限于传统的数据仓库技术手段，数据管理和分析能力成为信息化工作中的短板。企业信息系统众多，系统管理独立，数据存储分散，横向的数据共享和分析应用仅由具体业务驱动，难以对全局数据开展价值挖掘，从规模上和效果上都无法真正体现集团庞大数据资产的价值。市场竞争和产业链日益全球化，企业不只满足于内部数据的分析，更要通过互联网、微信、APP等新技术手段结合外部市场数据进行整体分析。传统的数据仓库不能满足数据分析需求 企业在数据分析应用方面呈现“五大转变”（从统计分析向预测分析转变、从单领域分析向跨领域转变、从被动分析向主动分析转变、从非实时向实时分析转变、从结构化数据向多元化转变），并且对统一的数据中台平台诉求强烈，对数据中台的运算能力、核心算法、及数据全面性提出了更高的要求。数据中台的处理架构发生了变化传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。一是以Hadoop、Spark等分布式技术和组件为核心的“计算&存储混搭”的数据处理架构，能够支持批量和实时的数据加载以及灵活的业务需求。二是数据的预处理流程正在从传统的ETL结构向ELT转变：5.1.2 阿里集团为什么要建立一个“大中台、小前台“？
我们从阿里共享业务事业部的发展史说起。起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀中台其实就是一个共享服务的体系结构。我们需要在日常的开发过程中将通用的服务抽离出来做到共享服务的体系结构当中。大中台，小前台的体系结构可以使得管理更加高效，小团队更加扁平化。由于资源的共享可以让开发更加敏捷，更能够知道需要做什么，该怎么做？通过抽象各条业务线，把共用的服务抽象出来共享，不限于用户、订单等基础模块服务，还包括具体的业务的抽象，比如教育培训相关的课程、讲师、学员等服务，通过抽象并以微服务的形式实现，避免重复投入资源造轮子。5.1.3 中台目标
首先、把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们从外呼业务中梳理出工单管理和问卷管理的能力；从知识库中梳理出知识搜索的能力；从85电商平台中梳理出商品销售和库存管理的能力等等。其次、将重复、类似的服务进行整合。同时在单个服务的完善和增强的过程中注意服务的通用性，避免其他相似“双胞胎”服务的出现。最后，由于服务能力的集中管控，很大程度会促进我们一体化运维的能力，但在“大中台、小前台”的模式下，每一个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力。5.1.4 中台分类
甄别是不是中台，还要回到中台要解决的问题上，一切以“以用户为中心的持续规模化创新”为目的，将后台各式各样的资源转化为前台易于使用的能力，帮助我们打赢这场以用户为中心的战争的平台，我们都可以称之为中台：业务中台提供重用服务 例如用户中心，订单中心之类的开箱即用可重用能力，为战场提供了强大的后台炮火支援能力，随叫随到，威力强大；数据中台提供了数据分析能力 帮助我们从数据中学习改进，调整方向，为战场提供了强大及时的雷达监测能力，帮助我们掌控战场；移动及算法中台提供了战场一线火力支援能力 帮助我们提供更加个性化的服务，增强用户体验，为战场提供了陆军支援能力，随机应变，所向披靡；技术中台提供了自建系统部分的技术支撑能力 帮助我们解决了基础设施，分布式数据库等底层技术问题，为前台特种兵提供了精良的武器装备；研发中台提供了自建系统部分的管理和技术实践支撑能力 帮助我们快速搭建项目，管理进度，测试，持续集成，持续交付，是前台特种兵的训练基地及快速送达战场的机动运输部队；组织中台为我们的项目提供投资管理、风险管理、资源调度等， 是战场的指挥部，战争的大脑，指挥前线，调度后方。所以，评判一个平台是否称得上中台，最终评判标准不是技术也不是长什么模样，最终还是得前台说了算，毕竟前台才是战争的关键，才是感受得到战场的残酷、看得见用户的那部分人。5.2 数据中台和数仓的关系
5.2.1 传统数仓
传统数仓有几个特点：数据具有历史性基于文件存储以表为形态，自带元数据存储（比如Hive）在数仓的数据是其他原始数据的拷贝或者拷贝的加工 传统数仓需要拷贝数据的重要原因是数据计算和数据存储需要尽可能的近。所以我们需要把MySQL等数据源的数据同步到数仓，才能进行进一步处理。（这里有点疑问，我觉得是因为需要直接对数仓数据进行离线操作，而不是对业务数据库进行繁重的操作，也就是说数据分析不能影响业务）另外传统数仓更关注的是数据的历史状态，所以导致数据规模庞大。数仓本身也具备计算能力，同时也可以作为存储供其他计算系统使用。5.2.2 数据中台
数据中台概念，不同于数据平台。数据中台，业务侧包含数据触手(埋点) 数据接入(标准化) 数据仓库(抽象化) 数据治理(可靠性) 数据服务(产品化)
数据服务接口
数据中台设计立足点本身是数据计算和存储分离的。那就意味着，数据中台本身并没有数据，数据来源是其他地方，比如传统数仓、业务数据库、用户在中台上传的文件（临时使用）、各个业务系统的API(瞬时，我们不关心API之前的数据结果是什么样的)。因为数据中台拥有这些数据源的适配器，所以相当于建立了互联管道。关于元数据
我们知道数仓的优势是有元数据，通过表的方式很好的规整了数据。数据需要加工，所以一般数仓是有分层的，往上走一层，数据信息损耗就高一些。数据中台也有一个全局的元数据管理系统，管理也是以表为主，粒度到字段级别。数据中台这个元信息包含了各个子存储的元信息，以数据中台需要的形态进行组织。数据地图
数据中台的元数据其中承载的一个重要功能是数据地图，虽然在数据中台中，修建了通往所有数据的道路，但是当用户进来的时候无法知道具体某个数据的地址，也就没办法利用这些修好的道路。数据地图就是解决这个问题 我们需要结合自然语言处理，检索技术，目录分类技术，机器学习以及数据规范化来帮助找到数据地址。数据地址从来都不是面向人类友好的。通过数据中台的数据地图，以及数据中台到各数据源的建立好的管道，那么我们就可以很好的找到我们要的数据以及对他们进行关联和处理，分析，甚至进一步成为机器学习的素材。数据地图和传统数仓元数据的区别在于：它记录了散落在各个孤岛的数据，而不像传统数仓，只是在自己的数据。数据格式是异构的，不仅仅是文件或表。他不仅仅存储表以及字段相关信息，同时还让这些信息可检索，可查询，可以更好的面向人而不是机器。5.2.3 结论
数仓是数据中台的一个重要组成部分，也是元数据的一个重要来源，但是随着技术的发展，数据计算和存储必定是分离的，这就需要一个新的元信息系统（数据地图）来进行承载。5.3 数据中台建设是数字化转型的支撑数据中台成为热点，“中台”这个概念，是相对于前台和后台而生，是前台和后台的链接点，将业务共同的工具和技术予以沉淀。数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台，在大数据生态中处于承上启下的功能，提供面向数据应用支撑的底座能力。广义上来给数据中台一个企业级的定义：“聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念”。5.4 公司平台分层与大中台小前台战略
5.4.1 互联网巨头“大中台，小前台”战略
阿里巴巴在2015年12月进行组织升级，就是“大中台，小前台”的模式。主要的思路是打破原来树状结构，小前台距离一线更近，业务全能，这样便于快速决策、敏捷行动；支持类的业务放在中台，扮演平台支撑的角色。其实，这个最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司:这家看似很小的公司，设置了一个强大的技术平台，来支持众多的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。对于这种多项目并行，各项目相对独立，但业务需求所需要的支持类似的公司，“中台”就有存在的价值。这种类似的思维应用到大企业中，就是需要一个资源整合和能力沉淀的平台，对不同的部门进行总协调和支持，“中台”也就应运而生。中台战略是构建符合DT时代的更具备创新性和灵活性的组织机制和业务机制，实现管理模式的创新。将公共的业务、数据、技术等公共能力从前台下沉，成为独立的中台，并且通过组织结构的调整物理拆分为独立的中台部门。大中台，小前台”适用场景不适合初创公司！初创公司的初创阶段没有任何的公共资源的积累，没有下沉为中台的内容。初创公司的首要任务是积累所有资源活下来，快速迭代主要业务，保存自己和核心竞争力。适合高速发展公司或者快速成长公司。有一定的公共资源的积累，公共部分下沉为中台，保其高可用高性能，为前端业务百花齐放，快速迭代提供坚实的后盾。5.4.2 公司平台分层
5.4.2.1 概述
阿里组织架构，业务中台、数据中台、技术中台公共组成中台。：前台
由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 app，微信公众号等都属于前台范畴。中台
“中台”的设置就是为了提炼各个业务条线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子”的KPI项目。“前台”要做什么业务，需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷。后台
由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。后台并不为前台而生另外，由于后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。5.4.2.2 敏捷前台/小前台
一线作战单元，强调敏捷交互及稳定交付的组织能力建设。对于阿里来说，小前台就是各个业务部门，个性化的各种前台服务，例如阿里的天猫、淘宝、河马、支付宝等一系列的品牌。5.4.2.3 业务中台
能力固化与赋能，固化通用能力，赋能前线部队，提升配置效率，加快前线响应，产品化业务化，开辟全新生态。具体来说，业务中台对应公司的公共基础业务和通用服务，例如短信中心、用户中心、支付中心交易中心、搜索服务等。下图中的公共逻辑层，就是业务中台。5.4.2.4 技术中台
技术中台主要负责基础服务、基础组件、基础平台、存储体系、云平台、运维相关等技术支撑。5.4.2.5 数据中台
负责大数据统计分析相关的DaaS（数据即服务）和PaaS（平台即服务）相关服务建设，资产整合与共享，整合多维数据，统一资产管理，连通数据孤岛，共享数据资源，深入挖掘数据，盘活资产价值。5.4.2.6 稳定后台
以共享中心建设为核心，为前中台提供专业的内部服务支撑。5.5 数据中台定义及处理架构
数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析，应用，使数据对内优化管理提高业务，对外可以数据合作价值释放，成为企业数据资产管理中枢。数据中台建立后，会形成数据API，为企业和客户提供高效各种数据服务。5.6 数据中台带来价值
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生，企业建设数据中台的最大意义就是应用与数据解藕。这样企业就可以不受限制地按需构建满足业务需求的数据应用。构建了开放、灵活、可扩展的企业级统一数据管理和分析平台， 将企业内、外部数据随需关联，打破了数据的系统界限。利用大数据智能分析、数据可视化等技术，实现了数据共享、日常报表自动生成、快速和智能分析，满足集团总部和各分子公司各级数据分析应用需求。深度挖掘数据价值，助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理，实现数据集中存储、处理、分类与管理，建立大数据分析工具库、算法服务库，实现报表生成自动化、数据分析敏捷化、数据挖掘可视化，实现数据质量评估、落地管理流程。5.7 传统数据仓库与数据中台的差异点
6.1 数据仓库vs.数据集市
数据集市和数据仓库经常会被混淆，但两者的用途明显不同。数据集市通常是数据仓库的子集;它等数据通常来自数据仓库 – 尽管还可以来自其他来源。数据集市的数据专门针对特定的用户社区(例如销售团队)，以便他们能够快速找到所需的数据。通常，数据保存在那里用于特定用途，例如财务分析。数据集市也比数据仓库小得多 – 它们可以容纳数十千兆字节，相比之下，数据仓库可以存储数百千兆字节到PB级数据，并可用于数据处理。数据集市可从现有数据仓库或其他数据源系统构建，你只需设计和构建数据库表，使用相关数据填充数据库表并决定谁可以访问数据集即可。6.2 数据仓库vs.ODS
操作数据存储(ODS)是一种数据库，用作所有原始数据的临时存储区域，这些数据即将进入数据仓库进行数据处理。我们可以将其想象成仓库装卸码头，货物在此处交付、检查和验证。在ODS中，数据在进入仓库前可以被清理、检查(因为冗余目的)，也可检查是否符合业务规则。在ODS中，我们可以对数据进行查询，但是数据是临时的，因此它仅提供简单信息查询，例如正在进行的客户订单状态。ODS通常运行在关系数据库管理系统(RDBMS)或Hadoop平台。6.3 关系型数据库vs.数据仓库和数据湖
数据仓库、数据湖与关系数据库系统之间的主要区别在于：关系数据库用于存储和整理来自单个来源(例如事务系统)的结构化数据，而数据仓库则用于存储来自多个来源的结构化数据。数据湖的不同之处在于它可存储非结构化、半结构化和结构化数据。关系数据库创建起来相对简单，可用于存储和整理实时数据，例如交易数据等。关系数据库的缺点是它们不支持非结构化数据库数据或现在不断生成的大量数据。这使得我们只能在数据仓库与数据湖间做出选择。尽管如此，很多企业仍然继续依赖关系数据库来完成运营数据分析或趋势分析等任务。内部或云端可用的关系数据库包括Microsoft SQL Server、Oracle数据库、MySQL和IBM Db2、以及Amazon Relational Database Service、Google Cloud Spanner等。我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！
数据治理怎么做？这篇万字长文终于讲清楚了！
关于OLAP数仓，这大概是史上最全面的总结！（万字干货）
如何利用阿里云大数据产品建设数据中台？
读书笔记 | 《大数据之路：阿里巴巴大数据实践》，DT时代的经验之谈！
全网最通俗易懂的HBase架构及原理